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ABSTRACT 



A method for a source to obtain the rights of a target object 
is disclosed. The source first obtains the rights of a source 
object, which rights include authorization to access a target 
object and to modify authentication data of the target object. 
Next, the source object generates new authentication data. 
After accessing the target object using the rights of the 
source object, the source modifies the authentication data of 
the target object to include the new authentication data. 
Using the new authentication data, the source obtains the 
rights of the target object, whereby the source becomes a 
proxy for the target object. As a proxy, the source uses the 
rights of the target object. Alternative processes for proxy 
authentication, as well as apparatus for proxy authentication, 
are also disclosed. 

38 Claims, 5 Drawing Sheets 
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METHOD AND APPARATUS FOR PROXY security, login security, and directory security. Each of these 

AUTHENTICATION examples of security regulate access to a network and its 

resources, and can be used independently or in conjunction 

TECHNICAL FIELD with one another, or with other forms of security. As the 

ll:e present invention relates generally to authentication ' ^^^^ ^^P^^^- Phy^j'^al security refers to limiting physical 

^ , . ^ 11 L r n J- 1 J ' access to a given network resource. For instance, servers in 

in computer systems, and will be specifically disclosed in „ ^ ° , u r* „ • . • ^ • i i i 

\ M 1 a client/server network are often maintained in a locked 

connection with authentication in a distributed directory. „ r™ *«^ » a a *u i r u • i 

^ room with hmited access. As a further example of physical 

BACKGROUND OF THE INVENTION security, a file server console or a workstation can be locked 

jQ requiring a password or key to access or utilize the server or 

Technological advances in microelectronics, digital workstation respectively 

computers, and software have resulted in a proliferation of ^o ^^^^ 

computer networks. In such networks, computers telecom- j„ ^^e next. One form of login security comprises a login 

municate between each other and share mformation, apph- ^^^^ authentication phase. The login phase typically 

cations and/or services. One type of computer network -^^^^^^^ prompting a source (such as a user, a program, a 

employs a chent/server architecture, wherein the portions of ^.g^^^^^^ ) ^^^^ attempting to enter the system for a 

network applications that interact with human users are name and a password. After successfully proving knowledge 

typically separated from the portions of network apphca- ^^c password, the source receives an encrypted private 

tions that process requests and mformation. Often, the ^ey from a server. Next, a credential is used in conjunction 

portions of an application that mteract with users or access ^-.^ ^^e private key to generate a signature. In the authen- 

ne work resources are called client applications or chent ^-^^^-^^ ^^^^ ^^^^ ^ ^^^^^ ^ ^^^^ 

software, and the portions of an appUcation that process ^^^^^ ^- ^^^^^ ^^^^^^^-^1 ^^^^^^^^ 

requests and information are called server applications or ^^^^ ^^^^ ^^^^^^ ^ p^^^j ^^-^^ 

server so ware. server. The proof is verified by the server through a com- 

One mechanism to maintain and access information putation using the source's public key stored in the source's 
across a network of computers is a distributed directory, object. If the proof is correct, then authentication is success- 
such as Novell Directory Services, which is based on the f^i and the source is allowed access to the system. After 
X.500 network services protocol developed and published successfully completing the authentication phase, the source 
by the CCIT and Open Systems Interconnection Consor- has "logged in"the system and is represented by an object 
tium. Usually, a distributed directory spans and is shared by 3^ identity on the distributed directory. The login phase is 
multiple networking servers. Infomiation on the distributed typically performed only once. However, if, for example, a 
du-ectory can be created, read, modified, and shared by connection needs to be made to other network servers, the 
network clients who have applicable access rights across the authentication phase can be repeated through a process 
plurality of servers. known as background authentication. This involves subse- 

The distributed directory contains a collection of objects, 35 quent verification by servers using the proof and the public 

sometimes referred to as identities, with associated attributes key without additional intervention by the source, 

or properties. For example, an object named "Computer" Directory security is usually used in conjunction with 

may have associated properties such as "Owner", login security, where directory security is not used unless 

"Operator", "Status", etc. Each associated attribute has a login security has been first verified. While directory secu- 

value. For example, the value for the property "Owner- 40 rfty can vary greatly, it generally comprises two parts: file 

"might be "George.ACME". Often, objects in the distributed system security and object security. FUe system security 

directory and their names represent things that humans relate provides access control to files and directories, and basically 

to when dealing with computers. For instance, some typical involves assigning trustee rights and file/directory attributes, 

objects might represent users, printers, print queues, files, Trustee rights assignments can be granted to any object in 

resources, computers, and the like. In addition, objects can 45 the distributed directory including container objects, user 

represent non-computer related things such as countries, objects, group objects, and organization roles. Examples of 

companies, organizations, departments, buildings, and the such rights include access control, supervisor, read, write, 

like. Furthermore, objects can be organizational in nature to create, erase, modify, and file scan. In contrast, file/directory 

group other objects together. As one with ordinary skill in attributes control what actions can or cannot be taken on a 

the art will readily appreciate, objects can represent virtually 53 file or directory. For example, certain files could be flagged 

anything, whether imaginary or real, and are not limited to as "read only" and "shareable" to prevent any unintentional 

the context of a distributed directory. or intentional deletions of such files or directories. 

Typically, the objects within a distributed directory are On the other hand, object security provides access control 

viewed by a user in a hierarchial structure, generally in the to directory objects and associated operations. Object secu- 

form of a tree, where the branches and leaves represent 55 rity generally includes object rights, properly rights, and 

objects. The distributed directory can additionally be orga- access control lists ("ACL's"). Object rights are granted to 

nized in partitions, with each partition comprising a plurality a particular object to access or manage another object, 

of objects organized as a subtree. Multiple replicas of the Examples of such rights include supervisor, browse, create, 

partitions are stored across the network, wherein each insu- delete, and rename. In contrast, property rights enable a 

lar server holds a unique set of partitions and therefore a eo trustee to view or change the values of a particular object's 

unique set of objects within that insular machine. Through- properties. A trustee could have rights to certain properties 

out the network, however, the overall hierarchy of the or to all properties of a particular object. For example, the 

distributed directory is preserved. supervisor property right over an object grants supervisor 

Access to network resources and objects can be regulated privileges for all properties in that object. All other rights 

to preserve security, 'lliis is particulariy desirable as net- 65 assignments made at the object level, however, are not 

works become larger and hold more important information. affected by the property rights. In fact, supervisor rights at 

Three examples of network security include physical the property level do not grant supervisor rights at the object 
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level. Only the reverse is true. The ACL is a special property whether the source object has rights to access or modify the 

of every object, which contains trustee assignments for an authentication data of the target object, or alternatively by 

object and its properties. Typically, an ACL is a tabulated checking whether the source object was assigned with proxy 

property containing three entries: the trustee ID, the type of rights to the target object. The target object has rights to 

access (i.e. object or property), and the actual rights assign- 5 access one or more objects. If the source object has proxy 

menl. A user object, for example, with the write right to the rights, the source object obtains the rights of the target 

ACL of another user object has what is known as "managed object. The source object then uses the rights of the target 

rights" over the user object. This means that an object with object to access the one or more objects. Optionally, one or 

the write right of an object ACL can make any rights more of the events that transpire while the source object is 

assignments to that object. lO the using the rights of the target object is stored. 

A principle known as "least privilege" teaches that a Still other aspects of the present invention will become 

source should have no more rights than is needed. By apparent to those skilled in the art from the following 

following this principle, accidental or malicious injury to a description of a preferred embodiment, which is simply by 

secured system can be reduced. However, in certain circum- way of illustration one of the best modes contemplated for 

stances it is desirable for a source to have extra rights or to ^5 carrying out the invention. As v^l be realized, the invention 

borrow the rights of an object, thereby acting as a proxy of is capable of other different and obvious aspects all without 

that object. However, existing computer systems and dis- departing from the invention. Accordingly, the drawings and 

tributed directories do not provide for a source to act as a descriptions are illustrative in nature and not restrictive, 
proxy for such objects. 



BRIEF DESCRIPTION OF THE DRAWINGS 



SUMMARY OF THE INVENTION 



FIG. 4 shows a flowchart of an alternative embodiment of 
the invention; 



The accompanying drawings, incorporated in and forming 

Accordingly, an objective of this invention is to provide part of the specification, illustrate several aspects of the 

a method and apparatus for proxy authentication. Additional present invention and together with their descriptions serve 

objectives, advantages, and novel features of the invention to explain the principles of the invention. In the drawings: 
will be set forth in part in the description that follows and in FIG. 1 depicts a schematic of a client/server network; 
part will become apparent to those skilled in the art upon ^ illustrates a computer with a source, and a distrib- 

exammmg or practicmg the mvention. The objects and ^jcd directory with a source object and a target object; 
advantages of the invention may be realized and obtained by _ , a x r . j • . 

c^x. • 4. * I*- J u- *■ 1 1 FIG. 3 shows a flowchart of a process embodying the 

means of the mstrumentalities and combmations particularly . . ^ ^ ^ 

• * J 4 • .u J J 1 • 30 mvention; 

pointed out in the appended claims. ^ * 

In one embodiment of the invention, a source obtains the 
rights of a vsource object. Preferably, the source is secured. 
Tlie rights of the source object include authorization to FIG. 5 illustrates an embodiment of the invention involv- 

access a target object and to modify authentication data of 35 i^g ^ print server, a printer, and a distributed directory; and 
the target object. The target object has rights to access one FIG. 6 illustrates a user source and a distributed directory; 
or more objects. Preferably, the rights of the source and Reference will now be made in detail to the present 

target objects are enforced by directory security. Next, the preferred embodiment of the invention, an example of which 

source generates new authentication data. Then, the source is illustrated in the accompanying drawings, wherein like 

accesses the target object using the rights of the source ^ numerals indicate the same elements throughout the views, 
object. The source proceeds to modify, at least partially due 

to the source having obtained the rights of the source object, DETAILED DESCRIPTION 
the authentication data of the target object to include the new piG_ \ illustrates a sample client/server network 10. As 
authentication data. Using the new authentication data, the one with ordinary skill in the art will readily appreciate, a 
source obtains the rights of the target object to access the one 45 client/server network is only one type of network, and a 
or more objects, whereby source becomes a proxy for the variety of other configurations, such as peer-to-peer 
target object. As a proxy, the source uses the rights of the connections, are also considered computer networks. The 
target object to access the one or more objects. server 12 is interconnected to a plurality of clients 14 using 
In another embodiment of the invention, a plurality of a connection 16 such as a token ring, ethemet, telephone 
computers access a plurality of objects in a distributed 50 modem connection, or the like. The security model 17 
directory. A target object in the distributed directory has illustrates the various security categories used in the network 
authentication data and rights to access one or more of the 10, including physical, login and directory security, A corn- 
plurality of objects. A source object has rights to access the puter readable medium 18, shown here as a floppy diskette, 
target object and to modify the authentication data of the holds information readable by a computer, such as programs, 
target object, and also has authentication data capable of 55 data, files, etc. Other examples of computer readable 
being obtained by a source. The computer system further medium include hard disk drives, compact discs, random 
comprises a generation mechanism operative to generate access memory ("RAM"), read only memory ("ROM"), and 
new authentication data for replacement of the authentica- the like. 

tion data of the target object. Also, the computer system FIG. 2 depicts a computer 20 on a network, and more 

comprises a replacement mechanism operative to replace the go specifically, a server in a client/server network. The distrib- 

authentication data of the target object with the new authen- uted directory 30 is shared by a plurality of computers over 

tication data, which enables the source to obtain the rights of the network, and contains a plurality of objects organized in 

the target object, hierarchial structure, shown here as a tree, where the 

In still another embodiment of the invention, a source branches and leaves represent objects. A source object 32, 

obtains the rights of a source object. Next, it is determined 65 called Serverl, represents the computer 20 and one or more 

if the source object has proxy rights to a target object. For of the programs loaded on the computer 20. For the purposes 

instance, such a determination can be made by checking of the specification and claims, a "program" is a process or 
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task capable of being run or executed on a processor. generating a random password and calculating a new 

Examples of programs include executable files, NetWare private/public key pair, however, a variety of other suitable 

loadable modules ("NLM"), dynamic link libraries means could be used. For instance, step 42 can be achieved 

("DLL"), batch files, threads, and the like. One such pro- by retrieving data from a table, using a time stamp, calcu- 

gram represented by the source object 32 is by the first 5 lating a password, etc. Step 43 involves the source 23 

program 22, called DS.NLM, which is running on the accessing the target object 36 by using the rights 33 of the 

computer 20 and supporting the distributed directory 30. The ^^rce object 32. In step 44, the source 23 modifies the 

^i^^r'Jli^A ^! T^''^ on the computer 20 entitled authentication data 38 of the target object 36 to include the 

? c . H T"""^ .tf "^Tu . 'a authentication data. Ideally.lhe new authentication data 

designed to dredge or otherwise traverse the distributed ^„ . , u- n * j * *u * * . 

directory 30 and extract object names, attribute syntaxes, ^ cryptographically transmitted to the target object 36. 

and values distributed across the directory 30, and to store Preferably, the new authentication data replaces the old 

this information in a static database. In this database, authentication data 38. This step 44 can be achieved at least 

searches for information may be performed rapidly without partially due to the source 23 having obtained the rights 33 

having to perform a potentially time consuming search over source object 32.. Upon the successful completion of 

the entire distributed directory 30. ^5 step 44, the source 23 is enabled to obtain the rights 37 of 

Authentication data 34 is associated with the source ^^"^S^^ object 36. 

object 32. For the purposes of the specification and claims. At step 45, the source 23 logs into the distributed direc- 

" authentication data" refers to information used to verify tory 30 using the new authentication data, thereby obtaining 

authenticity. Examples of authentication data include a the rights 37 of the target object 36, including the authori- 

proof, password, credential, public key, private key, and the 20 zation to access the one or more objects. By logging in as the 

like. The authentication data 34 can be used during the login target object 36, the source 23 becomes a proxy for the target 

phase or authentication phase, or both, of login security to object 36, and as a proxy the source 23 can use the rights 37 

verify the authenticity of the source 23 or the source object the target object 36, as shown in step 46, to perform its 

32. Subsequent verification can be achieved using back- dredeine operation 

ground authentication. 25 

-nie source object 32 also has rights 33 within the dis- . For the configuration illustrated in FIG. 2, the process 40 

tributcd directory 30. Directory security regulates these Preferably implernented using a series of Application 

rights 33, which can include authorization to access and Program Interfaces ( API s ) called in the program source 

modify certain objects within the distributed directory 30, ^^e source 23. Examples of suitable APFs for use in 

One such object is the target object 36. entitled Catalogl, 30 ^^""^^^ Distributed Services are as follows: 

which represents the catalog or database holding informa- AttachToFileServer: ms function attaches (i.e. estab- 

tion on the distributed directory 30. The target object 36 Ush&s a communication) the source 23 to a file server in a 

typically has extensive rights 37 to access many objects, if client/server network. The parameters include serverName 

not all objects, throughout the distributed directory 30. Like newConnlD. The parameter serverName points to the 

the source object 32, the target object 36 has its own 35 name of the server to be connected, which name can be 

authentication data 38, and its rights 37 can be controlled by reU-ieved using an API such as GetFileScrverName. The 

directory security. When the source 23 is executed on the parameter newConnID points to the new connection handle, 

computer 20, it will log into the distributed directory 30 and ^^e attachment was successful. Before attaching to the 

can be represented by the source object 32. The nature of the specified server, this function tries to get the server's net 

source 23 is that it needs to access a broad range of objects 40 address from the default server's Bindery. The function 

within the distributed directory 30 to effectively dredge, returns success or error codes. 

however, the source object 32 will most likely lack the NWDSGetServerDN: This function returns the server's 

necessary breadth of rights. distinguished name in the distributed directory 30. The 

The flow chart shown in FIG. 3 illustrates a process 40 for parameters include context, conn, and serverDN. The 

allowing the source 23 to obtain the rights 37 of the target 45 parameter context specifies the directory context for the 

object 36 to access one or more objects in the distributed request. The parameter conn specifies the connection to the 

directory 30, and thereby facilitate the source 23 to dredge server to be queried and is the connection handle to the 

the distributed directory 30. In step 41, the source 23 logs server. The parameter serverDN points to the distinguished 

into the distributed directory 30 as the source object 32. name of the server. The caller must allocate space to hold the 

Typically, the source 23 must be verified through some 50 distinguished name of the server and set serverDN to point 

security mechanism before this step can be completed. One to it. The size of the allocated memory is (MAX_DN_ 

suitable form of security is login security. In one CIIARS+l)*sizeof (character size) where character size is 1 

embodiment, the source 23 accesses the public/private key ^r single-byte characters and 2 for double-byte characters 

pair of the source object 32 through the first program 22, and (Unicode is double byte). One character is used for NULL 

uses the authentication phase of login security to log into the 55 termination. The function returns success or error codes, 

distributed directory 30. The ability to obtain the key pair is NWDSLoginAsServer: This function retrieves the 

due to the source 23 running on the same computer 20 as the authentication data 34 of the source object 32 and uses this 

first program 22, Because the source 23 can log into the data in the authentication phase of login security. The only 

distributed directory 30 by running on the same computer 20 parameter is context, which specifies the directory context 

as the first program 22, it is preferred that the computer 20 60 for the request. This function is only available to programs 

be physically secured. Having logged in as the source object running on the same computer as a program supporting the 

32, the source 23 has obtained the rights 33 of the source distributed directory, such as the first program 22. The 

object 32, including the authorization to access the target function returns success or error codes, 

object 36 and to modify the authentication data 38 of the NDSCGenerateRandomPassword: This function is a gen- 

targct object 36. 65 eration mechanism that generates a random alpha-numeric 

'Ilie next step 42 involves the source 23 generating new password. 'Ilie only parameter is objectPassword, which 

authentication data. Preferably, this step is achieved by points to the generated password. Alternatively, this function 
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could be substituted with code to generate the random request. The parameter optionsFlag is reserved value, which 

password. The function does not return a value. is passed in zero. The parameter objectName points to the 

NWDSGenerateObjectKeyPair: This function is a name of the object logging into the network. The parameter 

replacement mechanism that both creates or changes public/ password points to the client's current password in clear 

private key pair for a specified object. The parameters 5 text. If there is no password for the client, its value should 

include context, objectName, objectPassword, and options- point to a zero length string (""). If an apphcation has a local 

Flag. The parameter context specifies the directory context copy of any password value, the value should be erased as 

for the request. The parameter objectName points to the soon as possible to prevent compromising the security of the 

name of the object to update. The parameter objectpassword password. The parameter validityPeriod specifies the time 

points to the object password. If no password is desired, 30 'nterval in seconds during which the client's authentication 

objectpassword should point a zero length string ("")• If an remains valid. If the value is zero, the authentication service 

application has a local copy of any password value, the value ^^^^^^^ ^ j^f^^n ^^^^^ ^^-^ ^^^^^ ^^^^^^^ 

should be erased as soon as possible to prevent compromis- ^^f^^^ ^^^^^ j-^^ ^ authentication service, the 

mg the security of the password. Tlie parameteroptionsFIag ^^^^^^^ ^^j^^ ^ validation periods begins by 

IS a reserved value, which is pass in zero. The function n- t ^- tt. • • j j - j • 

J ^ callmg this function. The mmimum recommended period is 

returns success or error codes. . oi t . ■ 

60 seconds. Shorter times may cause the authenticator to 

NWDSI^gin: This fiinction performs all authentication before it can be used. If the authenticator expires 

operations needed to establish a connection to the network ^^^^^^ ^^^^^ ^^^^ ^ ^, 

and the network s authentication service. Until an authen- i^jT^i:.,.^ j 

. , , . • . ui- t. J 1- . 1 20 pleted. The function returns success or error codes, 

ticated connection is estabushed, the chent can access only *^ 

Directory information classified as public. The function Additional or alternative API's could be used to achieve 

caches authentication information locally to be used by other the process 40. Also, the precise use of these API's will 

functions and in background authentication to additional depend upon whether the source is a program, user, client, 

services. The parameters of this function include context, etc. For the process 40 depicted in FIG. 3, the following 

OptionsFlag, objectName, password, and validityPeriod. source code illustrates one way of using the above-listed 

'VhQ parameter context specifies the directory context for the API's: 



r 

Name: NDSCLoginTbCatalogObjcct 

Description: Called by NLM to create proxy object with that object's rights to the 
directory. 

Parameters: context -directory context used in calls to the directory. 

dnCatalog -distinguished name of catalog object. 

V 

* - 

int NDSCLoginToCatalogObject(NWDSContextHandle context, char *dnCatalog) 
{ 

NWDSCCODE ccode; 
int cntRetries - 3; 

char dnServeitMAX__DN_BYTES]; 
nLE_SERV_INFO serverlnfo; 
WORD connlD; 

char serverName[MAX__NAME__SIZE+l]; 

char password[MAX_PASSWORD_XEN+l]; 

/* Attach to file server V 

GetFiieScrverName( 0, serve rName ); 

ccode = AttachToFileServcr( serve rName, & conn ID ); 

/* Get the serve's DN */ 

ccode - NWDSGctServerDN( context, GetCurrentConnection( ), dnServer ); 

if (ccode) 

{ 

NWprintf( NDSC_GETSERVERDN„FAILED, ccode ); 
return ccode; 

} 

/* Log in as server to get access to server object */ 
ccode - NWDSLoginAsServer( context ); 
if (ccode) 
} 

NWprintf( NDSC_LOGrN_FAILED, dnServer ); 
return ccode; 

} 

/• Generate random password •/ 
NDSCGenerateRandomPassword( password ); 
/* Set new password */ 

ccode = NWDSGenerateObjectKeyPair( context, dnCatalog, password, 0 ); 
if (ccode) 

NWprintf( NDSC_GENKEYPAiR_FAIUID, ccode, dnCatalog ); 
if (! ccode) 
{ 

/• Now log in with that password - - retry for one half minute 

to allow for replication */ 
while (cntRetries - - > 0) 
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-continued 



{ 

ccode - NWDSLogin( context, 0, dnCatalog, password, 0); 
if (! ccode) 
break; 
delay( 100000 ); 

} 

if (ccode) 

printf(NDSC_IjOGIN_FAILED, ccode, dnCatalog ); 

} 

return ccode; 
} end NDSCLogLnToCataiogObj'cct**/ 



FIG. 4 illustrates an alternative process 50 for the source 
23 to become a proxy for the target object 36. In step 51, the 
source 23 logs in as the source object 32, and thereby obtains 
the rights 33 of the source object 32. Like the process 40, this 
step 51 can be achieved in a variety of ways, and preferably 
uses at least a portion of login security. At step 52, a 
determination is made whether the source object 32 has 
suflBcient rights 33 to become a proxy for the target object 
36. This can be achieved by determining whether the rights 
33 include authorization to access and/or modify the authen- 
tication data 38 of the target object 36. If the source object 
32 has such rights 33, the determination block 52 is positive. 
Alternatively, the determination step 52 can involve check- 
ing whether the source object 32 has been assigned a 
"proxy" right to the target object 36. Such a right can enable 
the source object 32 to obtain one or more of the rights 37 
of the target object 36. Preferably, this proxy right is 
enforced using directory security and will be listed in the 
ACL of the target object 36. If the proxy right has been 
assigned, the determination block 52 is positive. If, however, 
the determination block 52 is negative, the process 50 
proceeds to step 53 and is terminated. 

If the decision block 52 is positive, the process 50 
proceeds to step 54 where the source object 32 obtains the 
rights 37 of the target object 36. One way to achieve this step 
54 is to modify the source object's record in the connection 
table to reflect the rights 37 of the target object 36. However, 
doing so does not necessarily remove the source object's 
rights 33 in the connection table. Additionally or 
alternatively, the source object 32 can obtain the authenti- 
cation data 38 of the target object 36, preferably by changing 
the state of the source object 32 to the target object 36. In 
step 54, if an auditing of events is desired, one or more of 
the events that transpire while the source object 32 is 
accessing the one or more objects is stored. Preferably, only 
significant events, such as modifications, additions, dele- 
tions and the like, are stored. Also, it is preferred that a 
record be maintained that such events were performed by the 
source object 32 acting as a proxy for the target object 36. 
Such an audit record can be used to audit the activity of the 
source object 32, and avoid any potential misconceptions 
that the target object 36 was responsible for such events. At 
step 56, the source object 32 uses the rights 37 of the target 
object 36 to access one or more objects in the distributed 
directory 30. One difference between the process 50 and the 
process 40 is that the authentication data 38 of the target 
object 36 remains unchanged. This difference could be 
beneficial or detrimental depending upon the application. A 
further difference is that an audit of events from a proxy 
resulting from process 50 can identify the proxy as being 
responsible. 

FIG, 5 depicts an embodiment of the invention in the 
context of a print server 60. Loaded on the print server 60 
is a first program 61, entitled DS.NLM, which supports the 



distributed directory 63. A source 62, entitled 

15 PSERVER.NLM, is a second program loaded on the print 
server 60. Preferably, the print server 60 is physically 
secured. The distributed directory 63 is accessed by a 
plurality of computers on a network, including the print 
server 60. The source object 64, entitled Server2, is an object 

20 in the distributed directory 63 representing one or more 
programs loaded on the print server 60. The source object 64 
has rights 64B enforced by directory security to access and 
modify certain objects in the distributed directory 62. One 
such object is the target object 65, entitled PrintServer, 

25 which has access rights 65B to objects Queue 66 and 
Printer 1 67. The Queue 66 represents a printer queue and 
Printer 1 67 represents the physical printer 68. The source 
and target objects 64 and 65 have their own authentication 
data 64A and 65A, respectively. Using either the process 40 

30 or process 50, the source 61 can log into the distributed 
directory 63 as the source object 64, After having success- 
fully logged in, the source 62 can then take the appropriate 
actions to become a proxy for the target object 65, and 
thereby to access object Queue 66 and Printer 1 67. 

35 FIG. 6 shows yet another configuration where the present 
invention can be utilized, A source 70, which is a user, can 
log into the distributed directory 32 using login security, and 
be represented by the source object 74 entitled George. 
Because users do not have the security benefit of physical 

40 security, unlike servers 20 and 60, it is preferred that the 
source 70 be secured. This can be achieved using a biometric 
authentication security system 78 to verify that the source 70 
is not an intruder. Examples of biometric authentication 
include fingerprint comparison, retina scans, voice analysis, 

45 etc. The source object 74 has rights 74B, preferably enforced 
by directory security, to access other objects in the distrib- 
uted directory 72, and has its own authentication data 74A. 
The target object 76 also has rights 76B, preferably enforced 
by directory security, to access one or more objects in the 

50 distributed directory 72, and also has its own authentication 
data 76A. Using either the process 40 or 50, the user 70 can 
obtain the rights of the target object 76 and thereby become 
a proxy for the target object 76. 

The foregoing description of the preferred embodiment of 

55 the invention has been presented for purposes of illustration 
and description. It is not intended to be exhaustive nor to 
limit the invention to the precise form disclosed. Many 
alternatives, modifications, and variations will be apparent 
to those skilled in the art in light of the above teaching. For 

60 instance, each of the above examples used objects in the 
context of distributed directories, however, one with ordi- 
nary skill in the art will readily appreciate that the term 
"object" has meaning beyond distributed directories. Unless 
specifically qualified otherwise, the term "object" is not 

65 limited to distributed directories. Additionally, the invention 
has been illustrated in the context of networked computers, 
however, the invention can be used in stand alone computers 
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and/or processors. Likewise, the invention has utility in 
systems other than Novell Directory Services, including, for 
example, Windows NT, Windows 95, OS/2, Macintosh 
Operating systems, Vines, etc. Accordingly, this invention is 
intended to embrace all such alternatives, modifications, and 5 
variations that fall within the spirit and broad scope of the 
impended claims. 
What is claimed is: 

1. A method in a computer system, comprising the steps 

of: 

(a) obtaining by a source the rights of a source object, the 
rights of the source object including authorization to 
access a target object and to modify authentication data 
of the target object, the target object having rights to 
access one or more objects; 

(b) generating new authentication data by the source; 

(c) accessing the target object by the source using the 
rights of the source object; 

(d) modifying, at least partially due to the source having 
obtained the rights of the source object, the aulhenti- 20 
cation data of the target object to include the new 
authentication data; 

(e) using the new authentication data by the source to 
obtain the rights of the target object to access the one 

or more objects, whereby the source becomes a proxy 25 
for the target object; and 

(f) using by the source the rights of the target object. 

2. A method as recited in claim 1, wherein the source 
object represents one or more programs loaded on a com- 
puter. 30 

3. A method as recited in claim 2, wherein the computer 
is a server. 

4. A method as recited in claim 2, wherein the source is 
a program loaded on the computer. 

5. A method as recited in claim 4, wherein the source can 35 
obtain the rights of the source object at least partially due to 
the program is running on the computer. 

6. A method as recited in claim 1, wherein step (a) 
involves the source logging in as the source object. 

7. A method as recited in claim 1, wherein step (a) 40 
involves the source obtaining authentication data of the 
source object. 

8. A method as recited in claim 1, wherein step (b) 
involves generating a random password. 

9. A method as recited in claim 1, wherein step (d) 45 
includes the step of cryptographically transmitting the new 
authentication data to the target object. 

10. A method as recited in claim 1, wherein step (e) 
involves the source logging in as the target object using the 
new authentication data. 50 

11. A method as recited in claim 1, wherein the source 
object, target object, and one or more objects arc objects in 
a distributed directory. 

12. A method as recited in claim 11, wherein the rights of 
the source object and target object are at least partially 55 
enforced by directory security. 

13. A method as recited in claim 11, wherein steps (a) and 
(e) involve at least a portion of login security. 

14. A method as recited in claim 1, wherein the source is 
secured. 60 

15. A computer readable medium, comprising a program 
operative to perform the steps of: 

(a) obtaining by a source the rights of a source object, the 
rights of the source object including authorization to 
access a target object and to modify authentication data 65 
of the target object, the target object having rights to 
access one or more objects; 



(b) generating new authentication data by the source; 

(c) accessing the target object by the source using the 
rights of the source object; 

(d) modifying, at least partially due to the source having 
obtained the rights of the source object, the authenti- 
cation data of the target object to include the new 
authentication data; 

(e) using the new authentication data by the source to 
obtain the rights of the target object to access the one 
or more objects, whereby the source becomes a proxy 
for the target object; and 

(f) using by the source the rights of the target object. 

16. A computer system, comprising: 

(a) a distributed directory having a plurality objects; 

(b) a plurality of computers accessing the distributed 
directory; 

(c) a target object in the distributed directory having 
authentication data and rights to access one or more of 
the plurality objects in the distributed directory; 

(d) a source object in the distributed directory having 
rights to access the target object and to modify the 
authentication data of the target object, said source 
object having authentication data capable of being 
obtained by a source; 

(e) a generation mechanism operative to generate new 
authentication data for replacement of the authentica- 
tion data of the target object; and 

(f) a replacement mechanism operative to replace the 
authentication data of the target object with the new 
authentication data, which enables the source to obtain 
the rights of the target object. 

17. A computer system as recited in claim 16, wherein the 
source object represents one or more programs loaded on a 
computer. 

18. A computer system as recited in claim 17, wherein the 
computer is a server. 

19. A computer system as recited in claim 17, wherein the 
computer is physically secured, 

20. A computer system as recited in claim 16, wherein the 
authentication data of the target object includes a private/ 
public key pair, 

21. A computer system as recited in claim 16, wherein the 
replacement mechanism requires the rights of the source 
object to implement the replacement. 

22. A computer system as recited in claim 16, wherein the 
plurality of computers comprises a client/server network. 

23. A method in a computer system, comprising the steps 
of: 

(a) obtaining by a source the rights of a source distributed 
directory object in a distributed directory; 

(b) reading an attribute of one or more distributed direc- 
tory objects to determine if the source object has proxy 
rights to a target distributed directory object in the 
distributed directory, the target object having rights to 
access one or more objects in the distributed directory; 

(c) obtaining by the source object the rights of the target 
object, if the source object has proxy rights; and 

(d) using by the source object the rights of the target 
object to access the one or more objects. 

24. A method as recited in claim 23, further comprising 
the step of storing one or more events that transpire while the 
source object is using the rights of the target object. 

25. A method as recited in claim 23, further including the 
step of recording that the source object is acting as a proxy 
for the target object. 
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26. A method as recited in claim 23, wherein step (c) 
involves changing the state of the source object to the state 
of the target object. 

27. A method as recited in claim 26, wherein a record is 
maintained that the source object is a proxy for the target 5 
object. 

28. A method as recited in claim 23, wherein step (a) 
involves at least a portion of login security. 

29. A method as recited in claim 23, wherein step (b) 
involves at least a portion of directory security. lo 

30. A method as recited in claim 29, wherein the target 
object has authentication data and step (b) involves deter- 
mining whether the source object has rights to access the 
authentication data of the target object. 

31. A method as recited in claim 29, wherein the target is 
object has authentication data and step (b) involves deter- 
mining whether the source object has rights to modify the 
authentication data of the target object. 

32. A method as recited in claim 29, wherein step (b) 
involves determining whether the source object has been 20 
assigned proxy rights to the target object. 

33. A method as recited in claim 23, wherein the source 
is physically secured. 

34. A method as recited in claim 23, wherein step (c) 
preserves the rights of the source object. 25 

35. A method as recited in claim 23, wherein the computer 
system has a connection table with a record for the source 
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object and step (c) involves changing the record of the 
source object in the connection table to reflect the target 
object. 

36. A method as recited in claim 23, further comprising 
the step of storing in a database information read from the 
one or more objects. 

37. A computer readable medium, comprising a program 
operative to perform the steps of: 

(a) obtaining by a source the rights of a source distributed 
directory object in a distributed directory; 

(b) reading an attribute of one or more distributed direc- 
tory objects to determine if the source object has proxy 
rights to a target distributed directory object, the target 
object in the distributed directory having rights to 
access one or more objects in the distributed directory; 

(c) obtaining by the source object the rights of the target 
object, if the source object has proxy rights; and 

(d) using by the source object the rights of the target 
object to access the one or more objects. 

38. A method as recited in claim 24, further comprising 
the step of auditing the source by using the one or more 
stored events. 

^ >t> 9|e 3|C « 
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